【91 Q & A 時間】
### 想問91在公司中，如果團隊沒有 code review 習慣。有沒有什麼方法可以快速幫助工程師在程式撰寫優化上快速成長？
如果沒有 code review，並沒有產生任何問題跟負面影響，那為何需要 code review？
如果你們有共同面對一些問題要改善，是 code review 可能可以解決的，那就試著去改善、去解決你們碰到的問題。
如果有比 code review 更好的方式，那就用它，而不是執著在 code review。
#用成果要求他們
也就是，我們關注問題、需求、創造價值三個維度上，如果有待改善點，那就一起試著做點什麼來改善。
而我們看到的那些工程實踐、方法論、模式，就是因為這個世界上類似的問題，已經有人用類似的方式去改善跟解決了。那你們當然也可以試試看，因為我們不會比那些人更聰明、更厲害。
不要為了 agile 而 agile, 不要為了 TDD 而 TDD，為了滿足需求、解決問題、增加價值才需要引入改變。
「那對我們公司沒有用啦」
「喔？那你要不要提點有用的，然後試試看呢？是對你沒用，還是對你公司沒用啊？」
—
我還是覺得 code review 跟 pair programming 的效果很好。
上述的回答內容，只是希望順藤摸瓜，不是關注在「有沒有 code review」，而是有沒有改善 code 的品質，有沒有減少 bug，有沒有降低維護成本。
--
圖片致敬達叔：電影 《破壞之王》
#達叔RIP
—
突然發現我沒有回答到第二個問題，如何讓大家可以快速成長，如果真的要問我的話，兩個答案。
1. 來參加我的培訓。
2. 找我 coaching, 讓我跟團隊一起工作，讓他們從做中學。
唉，我也不是很想打廣告跟自吹自擂，但我真心覺得這是快又有效的方式。
你問我是怎麼學的？我也參加其他培訓呀。更細節的部分，我在商業思維學院分享過「技術工作者的商業思維」以及三月線下分享的「學習永動機」
雖然我毫不藏私地傾囊相授，也不見得聽的人就做得到，做得到也不一定適合你就是了。
但我可以說的是，不管是工作還是學習，還是技術變現、商業模式探索，我都是燃燒生命等級的熱血。（因為還有太多比我厲害的人比我認真和努力）
Search